To provide some background of a virtual machine, abstracted representations of several computing systems are first described. FIG. 1 depicts an abstracted representation of computing system 1 with a plurality of software applications (hereinafter, “applications”), a single operating system and physical hardware. Such components at times may be referred to as the different “layers” of the computing system (i.e., applications layer, operating system layer, physical hardware layer). The applications utilize the physical hardware (e.g., processors, memory, disk drives, network interface card, sound card, etc.) to help a user (not depicted) perform a specific task (e.g., word processing, surfing the web, etc.). The applications, however, typically do not interact directly with the physical hardware of computing system 1. Instead, the applications interact with the physical hardware through an operating system. For example, an application may send a request to the operating system to store data on a storage device of the physical hardware, and the operating system, in turn, may perform such request on behalf of the application. A single operating system typically hosts a plurality of applications, and accordingly, is tasked with managing how the applications share the resources of the physical hardware so that there are no contentions, data corruption, etc. On the other hand, the physical hardware of computer system 1 can typically only host a single operating system (or more precisely, only one operating system at any moment).
FIG. 2 depicts an abstracted representation of computing system 2 with an added layer between the operating system and the physical hardware. This layer is called the hypervisor (or also the virtual machine manager). In an analogous manner to how an operating system can manage how a plurality of applications share the resources of the physical hardware, the hypervisor can manage how a plurality of operating systems share the resources of the physical hardware. In computing system 2, the top two layers (i.e., applications and operating system) can be bundled together as a single unit, called a virtual machine.
Since the hypervisor allows a plurality of operating systems to execute at the same time, a plurality of virtual machines can also execute at the same time. Such an arrangement is depicted in computer system 3 of FIG. 3, in which the hypervisor hosts a plurality of virtual machines (VMs). Each virtual machine could be a virtual desktop, allowing a plurality of users to share the resources of the physical hardware. Alternatively, each virtual machine could be a web server and/or an application server, allowing a plurality of enterprises to share the resources of the physical hardware.
A virtual machine is typically characterized by the following information: virtual machine data, virtual machine configuration, and virtual machine operational state. Virtual machine data may refer to the contents of the virtual machine's hard disk (i.e., in-disk data). Such contents may include the virtual machine's operating system and application data. Typically, a virtual machine's hard disk does not correspond to a dedicated physical hard disk (i.e., physical hard disk that is dedicated to the virtual machine). Rather, a collection of hard disks is typically shared by a number of virtual machines. Consequently, a virtual machine's hard disk more accurately corresponds to portions of one or more physical hard disks that are accessible to the virtual machine. In some cases, a virtual machine's hard disk is represented by one or more files (e.g., .vmdk files) that are stored in the collection of hard disks. Virtual machine data may additionally refer to the contents of the virtual machine's memory (i.e., in-memory data). Typically, a virtual machine's memory does not correspond to a dedicated memory card or memory chip (i.e., memory card or memory chip that is dedicated to the virtual machine). Rather, a pool of memory (e.g., formed by a plurality of memory cards and/or memory chips) is typically shared by a number of virtual machines, so a virtual machine's memory more accurately corresponds to portions of one or more memory cards and/or memory chips that are accessible to the virtual machine.
Virtual machine configuration may refer to the hardware resources required or requested by a virtual machine (e.g., the number of virtual central processing units (CPUs), an amount of random-access memory (RAM), the number of network interface cards (NICs), etc., and what type of each hardware components, if the hardware components come in different types). A virtual CPU refers to one or more CPUs of the physical hardware that may be shared by one or more virtual machines.
Virtual machine operational state may refer to the operational state of a virtual machine (e.g., whether the virtual machine is powered off, powered on, suspended, whether the contents of the virtual machine's memory have been written to a VMkernel swap file, the number of virtual machine snapshots, the relationship between snapshots and the virtual machine's disks, etc.). Snapshots of a virtual machine are described below.
The state of a virtual machine typically refers to one or more of the virtual machine data, the virtual machine configuration, and virtual machine operational state at a particular point in time. In some cases, the state of a virtual machine refers to the virtual machine data, the virtual machine configuration, and virtual machine operational state (i.e., all three) at a particular point in time. It is noted that there is a potential for confusion in terminology as the “virtual machine operational state” is sometimes called “virtual machine state” by those in the field of the art, so it is necessary to rely on the context in which the term (i.e., virtual machine state) is used in order to determine whether virtual machine state refers to one or more of the virtual machine data, the virtual machine configuration, and virtual machine operational state at a particular point in time, or just the virtual machine operational state. To avoid such confusion, virtual machine state will hereinafter refer to one or more of the virtual machine data, the virtual machine configuration, and virtual machine operational state at a particular point in time. When referring specifically to the virtual machine operational state, the term “virtual machine operational state” will be used rather than the “virtual machine state”.
An operation that can be performed to preserve the state of a virtual machine at a particular point in time is called snapshotting. The information representing the state of a virtual machine at a particular point in time, after a snapshotting operation, may be called a virtual machine snapshot (or just a snapshot in short, if the context is clear). After a snapshot is taken at a particular time, a user can revert to the state of the virtual machine at that particular time (i.e., return one or more of the virtual machine data, virtual machine operational state, and virtual machine configuration to the state they were in at the time the snapshot was taken).
There are two types of virtual machine snapshots: crash-consistent snapshots and application-consistent snapshots. A crash-consistent snapshots only preserves the contents of a virtual machine's disk, whereas an application-consistent snapshot preserves the contents of the virtual machine's disk and memory. More precisely, data in the operating system's file system buffer (e.g., data that has been saved in the operating system's file system buffer but not yet saved on disk) may be saved in an application-consistent snapshot, but not saved in a crash-consistent snapshot. To elaborate, data may be saved in the operating system's file system buffer when an application (e.g., a word processing application) performs a save operation. On the other hand, unsaved application data (e.g., changes made to a Microsoft™ Word™ document that have not yet been saved) may not be captured by either a crash-consistent snapshot or an application-consistent snapshot.
In terms of performance, a crash-consistent snapshot has no impact (or very little impact) on the hypervisor or the virtual machine, as it is created and managed by the underlying disk storage (or disk storage system) without any interaction with the hypervisor. An application-consistent snapshot, on the other hand, does involve the hypervisor. First, the hypervisor flushes the in-memory data of the virtual machine to disk (e.g., creates a file on the disk storage system that holds a point-in-time copy of the in-memory data of the virtual machine). Second, the hypervisor makes the file (or possibly, plurality of files) that holds the in-disk data of the virtual machine read only and creates a separate file to store any new data or modifications to existing data. The former file (i.e., the file holding the in-disk data) is typically called the parent disk, and the latter file (i.e., the file storing new data or modifications to existing data) is often called the child disk (or delta disk). While crash-consistent snapshots have been described to offer a point of contrast to application-consistent snapshots, the remainder of the discussion will focus on application-consistent snapshots.
A virtual machine snapshot typically does not require the copying or duplication of any data (other than the point-in-time copy of the in-memory data of the virtual machine), but rather “freezes” the state of the virtual machine at a certain point in time by the creation of the read-only parent disk. If the user decides to restore the state of the virtual machine to that of the snapshot, the child disk is deleted and the virtual machine reverts to the state stored in the parent disk. Such operation is sometimes called “restoring” a snapshot. If the user decides that the snapshot is no longer needed (i.e., there is no longer a need to restore the virtual machine to the state when the snapshot was taken), the data of the child disk is incorporated (or merged) into the parent disk. Such operation is sometimes referred to as the “removal” or “deletion” of a snapshot.
While virtual machine snapshots are a useful administrative tool (e.g., allowing a user to restore a virtual machine to its state from an earlier point in time), virtual machine snapshots may negatively impact the performance of virtual machines and hypervisors. Such performance impact and techniques to address same are discussed herein.